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BSA | The Software Alliance appreciates the opportunity to provide feedback to the National 
Institute of Standards and Technology (NIST) regarding the Initial Draft of the Al Risk 
Management Framework (Al RMF).' BSA is the leading advocate for the global software 
industry before governments and in the international marketplace. Our members are at the 
forefront of software-enabled innovation that is fuelling global economic growth and helping 
businesses of all sizes leverage the benefits of cloud computing and Al-enabled products 
and services.* As leaders in Al development, BSA members have unique insights into both 
the tremendous potential that Al holds and the policies that can best support responsible Al 
innovation. 


NIST’s development of an Al RMF has the potential to serve as a much-needed foundation 
for global Al risk management efforts. By establishing a shared conceptual framework for 
identifying and mitigating risks throughout the Al system lifecycle, the Al RMF can serve as 
a common reference point that will facilitate communication between the many 
stakeholders involved in (or potentially impacted by) the development and deployment of 
an Al system. Given the global convergence around the need for risk-based regulatory 
approaches for Al, the Al RMF also has the potential to serve as an important tool for 
organizations to comply with emerging international legal requirements. More 
fundamentally, although the Al RMF is an inherently non-regulatory instrument, it can help 





1 Al Risk Management Framework: Initial Draft - March 17, 2022 (nist.gov) 

2 BSA’s members include: Adobe, Alteryx, Atlassian, Autodesk, Bentley Systems, Box, Cisco, 
CNC/Mastercam, DocuSign, Dropbox, IBM, Informatica, Intel, MathWorks, Microsoft, Okta, Oracle, 
Prokon, PTC, Salesforce, SAP, ServiceNow, Shopify Inc., Siemens Industry Software Inc., Splunk, 
Trend Micro, Trimble Solutions Corporation, Twilio, Unity Technologies, Inc., Workday, Zendesk, and 
Zoom Video Communications, Inc. 
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inform future regulatory efforts by providing a shared understanding about the multiple 
stakeholders, key considerations, and difficult trade-offs involved in effective risk 
management. 


The Initial Draft represents a significant step toward achieving the full potential of the RMF. 
We are particularly encouraged by the Initial Draft’s recognition that evaluating Al risk is an 
inherently context-specific inquiry that must account for the particular manner in which a 
system is (or will be) deployed. As the Initial Draft acknowledges, the risks implicated by an 
Al system, the appropriate measures for mitigating identified risks, and the appropriate 
thresholds for evaluating acceptable vs. unacceptable risk cannot be evaluated in the 
abstract. Instead, as the Al RMF recognizes, they must be informed by an understanding of 
the broader context in which the system will operate, including the “setting in which the Al 
system will be deployed,” the business purpose it will be used for, and the “specific task” 
that it will support. 


While effective risk management requires an informed understanding about how a system 
will be used, the groundwork for risk management must be laid far before a system is 
deployed. We therefore agree strongly with the Initial Draft that “risk management should 
be performed throughout the Al system lifecycle to ensure it is continuous and timely.” In 
fact, the importance of a lifecycle-based approach to Al risk management prompted our 
recent effort to develop a framework for managing the risks of Al bias. The BSA Framework 
to Build Trust in Al (BSA Framework), outlines a methodology for performing impact 
assessments and corresponding best practices for mitigating risks that are pegged to the 
specific activities that occur at each stage of the Al lifecycle, including Design (i.e., project 
conception and data collection), Development (i.e., data preparation, model definition, 
validation, and testing), and Deployment. 


Overall, the Initial Draft is built on a solid foundation. However, the ultimate success of the 
Al RMF will depend on ensuring that it is both flexible enough to accommodate the wide 
range of Al use cases, but specific enough so that it can serve as a useful mechanism to 
guide risk management practices. To assist NIST in striking that balance, we provide below 
a series of recommendations aimed at improving the usability of the framework and 
aligning it with industry best practices. In addition to the conceptual and structural 
recommendations below, we have attached an initial attempt to create a “crosswalk” 
comparison of the NIST Al RMF to the BSA Framework. We are pleased that the crosswalk 
demonstrates is a high degree of overlap between the BSA Framework and the Initial Draft. 
Included within the crosswalk are a number of specific recommendations for NIST’s 
consideration that would help to fill in potential gaps in the Al RMF’s categories and 
subcategories. 


Recognizing that Al Risk Management is a Shared Responsibility 


The Initial Draft would benefit from a discussion or guidance to help stakeholders navigate 
the complexities involved in Al risk management in circumstances where there may be 
multiple stakeholders involved in the development and deployment of an Al system. As 
currently drafted, the Framework Core in many ways seems to presuppose that the 
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organization using the Al RMF will have full visibility into and control over the entire lifecycle 
of the Al system it is evaluating. For instance, while the Map Function largely focuses on an 
analysis of a system’s deployment context,’ it also calls for an examination of system 
artefacts that may only be available to the entity that trained the underlying model. 


The Framework Core provides little guidance about how organizations should utilize the 
RMF in circumstances where they are preparing to deploy an Al system or capability that 
may have been acquired from a third-party vendor.® Similarly, the Framework Core 
provides little guidance to vendors of general-purpose Al systems that may have limited 
insight into how their customers deploy the system. 


NIST should consider adding high level guidance to Part 1 of the RMF to explain that risk 
management will in many instances be a shared responsibility that encompasses multiple 
entities, including organizations that develop Al systems for use by third parties (i.e., Al 
Developers) and entities that deploy Al systems that they have acquired from third parties 
(i.e., Al Deployers). While NIST should avoid drawing any bright lines about how specific 
responsibilities should be assigned, it would be helpful for the Al RMF to acknowledge that 
the appropriate allocation of risk management will depend on the nature of the underlying 
model and the extent to which it may be customized and/or re-trained by the Al Deployer. 6 
Such guidance would serve as a useful tool for facilitating conversations between vendors 
of Al services and their customers to ensure that there is a shared understanding about 
their respective roles and responsibilities. 

In addition, NIST should consider sub-dividing the “Al System Stakeholder” category in the 
Audience section of the Initial Draft. The Draft currently characterizes the Al System 
Stakeholder category as “those who have the most control and responsibility over the 
design, development, deployment and acquisition of Al systems, and the implementation of 
Al risk management practices.” As noted above, not all System Stakeholders (as that 
category is currently defined) will have control over the full lifecycle of an Al system. NIST 





3 For example, the subcategories in the Map Function calls for an analysis of the “intended purpose 
[and] setting in which the Al system will be deployed,” the “business purpose and context of use,” and 
the “operation context in which the Al system will be deployed.” 

4 For example, Map ID 2 includes a subcategory that is focused on “considerations related to data 
collection and selection.” While it is not made explicit, it would appear that this subcategory is focused 
on training data. 

5 The Governance Function does acknowledge the importance of maintaining policies to “address Al 
risks arising from supply chain issues” including the “value and trustworthiness of third-party data or Al 
systems.” But, beyond the mention of supply chain risk, the Framework Core lacks meaningful guidance 
about how to navigate these risks. 

ê The OECD for the Classification of Al Systems adopts a similar approach for assigning risk 


management responsibilities. See OECD Framework for the Classification of Al Systems, February 
2022, https:/Awww.oecd-ilibrary.org/docserver/cb6d9eca- 

en.pdf? expires=1649808351 &id=id&accname=guest&checksum=74B738F 154B4F05D18B7B3D8B34 
77CE0, p. 48. 
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should therefore consider either teasing out “Al Developer” and “Al Deployer” organizations 
into separate (but potentially overlapping) categories’ and/or acknowledging that not all “Al 
System Stakeholders’ will have full control over an Al system’s lifecycle. 


Finally, NIST should carefully scrutinize the use of the various Al System Stakeholder 
designations throughout the document to ensure that the RMF paints an accurate picture 
about their respective roles, responsibilities, and capabilities. We note for instance, that the 
discussion of “Technical Characteristics” on page 8 suggests that Al system accuracy, 
reliability, robustness, and resilience are “factors that are under the direct control of Al 
system designers and developers.” While it is true that Al system developers will in many 
circumstances have control over the accuracy of an Al system prior to its deployment, such 
control may be severed in instances when the system is deployed by a third-party. More 
generally, NIST should take care to avoid using Al stakeholder terminology in ways that 
may give rise to unintended interpretations or the appearance of policy preferences. We 
note for instance that the term “auditors” in the Operators & Evaluators Stakeholders 
grouping could be misconstrued as a reference only to third party organizations rather than 
in-house personnel. We urge NIST to clarify that the “auditors” referenced in the Al RMF 
can be personnel within an Al Developer or Al Deployer organization. 


Provide Additional Guidance Regarding Use of the Al RMF Technical and 
Sociotechnical Characteristics and Clarify the Relationship to Impact Assessments® 


The Initial Draft sets forth a risk assessment method that is centered around an analysis of 
a system’s “technical” characteristics (i.e., accuracy, reliability, robustness, resilience/ML 
security), its “socio-technical” characteristics (i.e., explainability, interpretability, privacy, 
safety, and managing bias), and a broader set of “guiding principles” (i.e., fairness, 
accountability, and transparency). For instance, the Map Function calls for: 


e An analysis of the “potential business and societal (positive or adverse) impacts of 
technical and socio-technical characteristics for potential users, the organizations, or 
society” 

e An elucidation of a system’s “potential harms...along technical and socio-technical 
characteristics” to ensure alignment with “guiding principles” 


Similarly, the Measure Function calls for: 


e Anevaluation of “accuracy, reliability, robustness, resilience (or ML security), 
explainability and interpretability, privacy, safety, bias, and other system performance 
or assurance criteria.” 





7 See page 18 of the BSA Framework for a discussion of the relationship and definitions of key 
stakeholder groups: Al Developers, Al Deployers, and Al End-Users. 

8 This section includes recommendations that are responsive to NIST’s question about “[w]hether the Al 
RMF enables decisions about how an organization can increase understanding of, communication 
about, and efforts to manage Al risks.” 
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We agree that an analysis of these system characteristics is an important element of 
effective risk management. However, the RMF provides little guidance about how these 
technical and sociotechnical characteristics should be used to guide the risk assessment. 
In the absence of additional explanation or guidance, we are concerned that characterizing 
the risk assessment process as centering on system characteristics may inadvertently 
suggest that Al risk management can be accomplished by looking only at attributes of the 
Al system in isolation from their impact on people. We recognize, of course, that this is not 
NIST’s intent. Indeed, the Framing Risk section acknowledges that a core objective of Al 
RMF is to help organizations manage “enterprise and societal” risks and thereby prevent 
individual, organizational, and systemic harms. 


We encourage NIST to provide additional clarification about how organizations should use 
the “technical and socio-technical characteristics” as heuristics for analyzing what impacts 
a system may have on internal and external stakeholders. It would be helpful, for instance, 
to include a sample analysis of a hypothetical Al system to demonstrate how “potential 
harms” can be “elucidated along technical and socio-technical characteristics and aligned 
with guiding principles” as contemplated by Map ID 4 Subcategory 2. Such guidance could 
be included in the “Practice Guide” that the Initial Draft mentions is currently under 
development. 


As NIST considers how to structure potential additional guidance and/or adjustments, we 
recommend that it consider embracing the concept of “impact assessments” as a 
mechanism for assessing Al system risk. As noted in NIST Special Publication 1270, 
“impact assessments” are a “high-level structure that enables organizations to frame the 
risks of each algorithm or deployment while accounting for the specifics of each use case.”° 
By clarifying that the risk analysis under the Al RMF should focus on the “impacts” of an Al 
system and providing more clarity about how the technical and socio-technical 
characteristics of Al systems should be used as part of that holistic examination, the 
Framework will better serve the needs of its target audience. 


Focus on “Consequential” Al Systems 


We recognize that the Al RMF is an explicitly voluntary resource that is intended to be 
flexible enough to accommodate systems of all kinds. However, given that the RMF is 
intended to serve as a resource for organizations of all sizes and “level[s] of familiarity” with 
Al, we urge NIST to consider adding in some high-level guidance to help organizations — 
particularly those who may be resource constrained — to identify Al systems within their 
purview that should be prioritized for assessment under the RMF. 





See NIST Special Publication 1270, Towards a Standard for Identifying and Managing Bias in Artificial 
Intelligence (nist.gov) 
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As you know, Al and Al-enabled features are now integrated into a staggering array of 
products and services that range from the trivial to the mission critical. Whether it is word 
processing software that uses ML-powered font recognition or email systems that utilize 
neural networks to detect spam, today’s organizations may rely on an untold number of 
products and services that utilize some form of Al. As a practical matter it will be impossible 
for any organization to use the Al RMF to assess every Al-powered feature within an 
organization’s supply chain. Unfortunately, the Initial Draft of the RMF currently lacks any 
guidance to help organizations identify the types of Al that should be prioritized for 
assessment via the RMF. 


We recommend that NIST provide high level guidance to help organizations identify the 
“consequential” Al systems that should be prioritized for assessment under the RMF. Such 
guidance could highlight suggested criteria and/or questions for assessing whether a 
system is consequential. For instance: 
e Is the system vital to an organization’s ability operate? 
e Is the system used in a manner that may produce legal effects on people and/or 
determine eligibility for important life opportunities? 
e Could the system pose a risk of significant physical or psychological injury or 
otherwise threaten an individual’s human rights? 


We appreciate the tremendous work that is reflected in the Initial Draft of the RMF and 
thank you for taking our recommendations into consideration. 


Sincerely, 


Christian Troncoso 
Senior Director, Policy 
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